OGSA-DAI Usage Scenarios and Behaviour: Determining good practice

OGSA-DAI has been developing Grid middleware for over two years now. A high profile project within the Grid community OGSA-DAI is increasingly being used by Grid based projects to provide their Data Access and Integration (DAI) requirements. From a simple set of services relatively sophisticated usage scenarios may be realised. This presentation examines a number of DAI scenarios identified by OGSA-DAI and the GGF DAIS working group and demonstrates how the existing OGSA-DAI framework satisfies them. A number of real use-cases from the projects that are using OGSA-DAI are outlined and gaps within the existing OGSA-DAI framework are identified. The OGSA-DAI software distribution and further information about the project is available from the project website at http://www.ogsadai.org.uk/. 1 Data Access and Integration Scenarios To date, most of the effort in the Open Grid Services Architecture – Database Access and Integration (OGSA-DAI) project has concentrated on developing an extensible document-based framework that provides uniform data access mechanisms for a number of different data resources, i.e. mainly relational and XML based databases although there is also some support for accessing files through OGSA-DAI. Currently the framework used by OGSA-DAI is described in the draft Grid Database Service Specification, [1], of the Global Grid Forum's (GGF) Data Access and Integration Services (DAIS) Working Group as presented at GGF7. Although this viewpoint no longer aligns with the current direction of the DAIS specifications there are no real inconsistencies between the two approaches – differences arise mainly in the granularity of the requests going to the services. At some future point OGSA-DAI will adopt the presently defined DAIS interfaces although the document based access method will still be actively supported. Basic data integration capabilities are currently not as well supported through the existing framework although it is possible to do this using the existing core OGSA-DAI distribution. However, this relies on an OGSADAI client explicitly chaining services together – clearly this is neither a scalable solution nor necessarily an easy one to implement. Work is currently underway at EPCC investigating simple data integration scenarios with a view to understanding how well the existing OGSADAI distribution serves this and to try and identify what additional functionality might be added to facilitate data integration capabilities. It is worth noting though that OGSA-DAI does not have to provide the whole of the data integration layer. Instead, it can exploit data integration capabilities provided by the data resource themselves or through some other third party means and wrap these data resources, already constituting a federated resource, which may then be further federated with additional data resources of different types by an OGSADAI layer. This model of operation is similar to one used by the eDiaMoND project (see below). However, as things stand, we find that the data access scenarios (1-6) and data integration scenarios (7,8) identified by Greg Riccardi and Simon Laws, shown in Figure 1 below, can all be supported by the current OGSA-DAI distribution. In addition, many of the data access and integration requirements of existing projects employing OGSA-DAI may be classified under these scenarios. More sophisticated data integration capabilities are realisable via Distributed Query Processing (DQP), currently available as a separate package that may be downloaded from the OGSA-DAI web site. DQP is layered over OGSA-DAI providing an additional abstraction layer that allows queries to be applied to various relational data resources as though they were a single logical resource. This is done through an additional set of Grid services that extend the scope of OGSADAI: one of these services acts as the point of contact for a client and orchestrates other services behind the scenes, including services that evaluate queries on each data resource. Data integration scenarios can be managed at either the client or service end; DQP illustrates an extension to OGSA-DAI at the service end, enabling data integration. Future work within OGSA-DAI will investigate to see whether it is possible to integrate this type of functionality directly on to the core OGSA-DAI distribution. Key to Symbols